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Audience  Assumptions  For  This  Presentation 
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•  Software  projects  exist  for  which  agile  development  process  provide 
a  greater  chance  of  success  than  a  traditional  waterfall  life-cycle 


•  Agile  is  not  an  excuse  for  ignoring  processes,  management,  or 
engineering 


•  Agile  produces  useful  programmatic  metrics 
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Four  Questions  From  I  implementing  Agile  EVM 
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•  '"What  is  different  about  Agile  EVM  from  EVM" 


•  "Agile  metrics  and  charts  provide  insight  into  progress,  but  how  is 
the  project  proceeding  according  to  the  plan?" 


•  "How  do  I  report  SPI  and  CPI  for  an  agile  project?" 


•  "How  do  I  get  credit  for  work  partially  completed  in  a  fixed 
timebox?" 


3 


©Copyright  2009  Northrop  Grumman 


Agile  Requirements 
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Traditional  Systems  Engineering 


Agile  Systems  Engineering 


Many  Layers  of  Functionally  Decomposed 
Requirements  Ending  in  Atomically 
Described  Functions 


Many  Layers  of  Functionally  Decomposed 
Requirements  Ending  in  Deliverable 
Capabilities  Useful  to  User 
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Key  Differences  -  Part  1 
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Focused  on  Delivering  Capabilities 

•  Manage  based  on  delivery  of 
capabilities  scheduled  into  fixed  time- 
boxes 

•  Identify  tasks  required  to  deliver  each 
story 

•  Manage  risks  while  identifying  all 
tasks  necessary  to  complete 
capabilities 


Focused  on  Completing  Activities 

•  Manage  based  on  the  completion  of 
activities  broken  down  into  small 
duration  tasks 

•  Manage  risks  while  identifying  all  tasks 
necessary  to  complete  the  system 
requirements 
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Key  Differences  -  Part  2 
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Agile  planning  balances  the  effort  and 
investment  in  planning  with  the 
knowledge  that  the  plan  will  be  revise 
through  the  course  of  the  project 

Well  suited  for  6  to  18  month  long  projects 
or  increments  of  larger  programs 

Allows  requirements  to  flex  to  meet 
business  and  mission  needs 

Typically  does  not  perform  complete 
planning,  scheduling,  and  costing  of  a 
project  to  discrete  work  packages  to  the 
same  level  of  details  as  traditional  EVM 
efforts 


Cost  I  mpact  of  Requirements 
Change  Over  Project  Lifecycle 
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•  What  does  it  cost  to  change 
the  width  of  an  aircraft  carrier? 

•  How  would  ship  design  change 
if  it  was  inexpensive? 
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Key  Differences  -  Part  2  -  Balances 
Constraints 
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Key  Differences  -  Part  3  &  4 


NORTHROP  GRUMMAN 


Project  teams  commit  to  delivering  specified  amount  of  capabilities 
or  requirements  in  a  fixed  time  versus  tasks  in  a  specified  time 

-  Measured  in  story  points 

-  Establish  'Velocity"  of  story  points  per  time  (i.e.  iteration  or  release) 


•  Agile  takes  credit  for  integrated,  and  delivered  code  while  EVM 
credits  value  when  tasks  are  complete 

-  Agile  uses  a  customer  centric  definition  of  value  aligned  to  features  and 
requirements  over  programmatic  activities 

-  'Value  delivered  earlier" 
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Agile  Progress  Charts 


"Something  is  "Missing 
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Release  Burnup 

Spin  2  (04/01/09  -  06/30/09) 
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'That  is  great,  but 
what  was  the 
original  plan?" 

Iteration  Burndown 

Spin  2  Iteration  3  (04/27/09  -  05/08/09) 
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Accepted  (Points) 


Planning  Scope  For  Agile 


•  Plan  for  6  to  18  month 
durations 


•  Baseline  project  capacity  in 
story  points 


Project  level  (12  months) 

Release/spin  level  (3 
months) 


-  Iteration  level  (2  to  4 
weeks) 


•  Track  and  calculate 
progress  (SPI)  against  the 
story  point  plan 

•  Get  Engineering  Team 
participation 
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Story  Points 


"Filling  EVM  Gap" 
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Earned  Value  Plan 


■Cumm  Plan 

■Cumm. 

Earned 

Earned  Value 
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New  Way  Of  Approaching  SPI 
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•  How  to  get  less  than  or  greater  to  1.0  in  a  fixed  duration  timebox  ? 

-  Traditionally 

•  “Complete  scheduled  tasks  slower  or  faster  than  planned." 

-  Agile  EVM 

•  "Deliver  or  complete  more  or  less  work  than  planned." 


•  Why 


Agile  uses  fixed  timeboxes  to  schedule  work  and  varies  the  amount  of 
scope  in  a  timebox 
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When  to  Replan  and  When  to  Take  Credit  for  1.0+ 
SPI? 
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•  Scenario 

-  A  project  is  able  to  take  on  more  work  than  originally  planned  in  a 
release 

•  Agile  EVM  Recommendation 

-  Move  stories  forward  or  add  stories  from  existing  project  backlog 
(SPI  >  1.0) 

-  Replan  to  increased  scope  if  added  stories  are  not  in  current 
backlog  (  SPI  =  1.0) 

& 
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Lessons  Learned 
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•  Allow  late  acceptance  for  small  amounts  of  remaining  work  (<  10% 
iteration) 

•  Split  story  points  on  release  boundaries  for  large  amounts  of 
carrying  over  work  for  accepting  stories 

•  SPI  is  measured  for  the  entire  "contractual"  effort  (i.e.  I  ncrement  X) 

•  Deferred  or  antiquated  requirements  are  removed  from  backlog 
thus  reducing  the  total  story  points  or  replaced  with  new 
requirement  of  equal  story  point  value 
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When  to  Take  Credit  For  Value 
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•  When 

-  Development  complete?  -  I  ntegration  and  testing  complete? 

-  Working  in  field?  -  After  certification  and  accreditation? 


Many  domains  have  extensive  external  certification  processes  that 
delay  actual  fielding 

Recommendation 

-  If  delivery  and  deployment  time  is  significantly  less  than  the 
development  and  testing  time 

•  Take  credit  for  value  after  demonstration  in  the  field 

-  Else 


•  Take  credit  after  an  integration  and  test  milestone  that 
demonstrates  acceptable  levels  of  confidence 

•  Defect  process  will  account  for  rework 

•  Iterative  aspect  of  agile  reduces  risk  of  costly  defects  leaking 
through  to  field 
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When  to  Take  Credit  For  Value  -  Partial  Credit 
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•  "Pure"  Agile  does  not  give 
partial  credit 

-  Similar  to  EVM's  0,100  credit 
concept 

•  0,100  Model  can  cause 
undesirable  variances  for 
projects  where  delivery  time 
is  large  with  respect  to 
development  time 

-  Good  candidate  for  0,50,100 
or  0,85,100  approach  for 
credit 


Try  to  avoid  a  reporting 
process  that  likely  cause 
variances 


Expected  Hours  Spent 

Expected  Points 
Earned 
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Summary 
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Agile  EVM  Papers,  experience,  and  tools  support  that 
Agile  can  provide  metrics  that  feed  a  more  traditional 
EVM  approach 

-  "AgileEVM  -  Earned  Value  Management  in  Scrum 
Projects",  Suliarman,  Barton,  and  Blackburn 

Agile  EVM  takes  a  mind-set  adjustment  focused  on 
planning,  delivering,  and  reporting  on  value  earned 
for  capabilities 

Agile  EVM  is  a  minimal  project  burden  for  disciplined 
agile  projects 
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